[Previous] [Next] [Index]
[Thread]
Re: GSS API (as a DLL)...
At 01:17 PM 8/18/94 -0400, Rens Troost wrote:
>
>>>>>> "Ken" == Ken Shores <kss1376@pop.draper.com> writes:
> Ken> At 03:27 PM 8/17/94 TZ, John Ludeman wrote:
> >> ---------- | From: "Alec H. Peterson" <chuckie@panix.com> |
> >> Date: Wednesday, August 17, 1994 4:46PM | | Ramin Firoozye
> >> writes: | [...] | > | >The BIG problem specific to security
> >> DLL's is that someone bent on breaking | >security can write a
> >> "wrapper" DLL around a security DLL, store all the | >[...] | |
> >>
> >> No, this is not a valid reason. The above argument implies there
> >> is no security. If a sysadmin doesn't want this to happen, they
> >> must take the appropriate security percautions. If they do not,
> >> then *nothing* in the system is secure and any program the system
> >> might run can do bad things. This again gets into site security
> >> issues which is beyond the topic of this alias.
>
> Ken> I'm inclined to agree. If you can compromise the users loader
> Ken> library search path, then you're probably in a position to
> Ken> compromise the path used to load applications as well, and
>
>No, he's right. System security things should be statically
>linked. Especially on Suns, with their LD_PRELOAD functionality. Most
>well written (from a security point of view) software that needs to
>exec other stuff will do so with a full pathname, thus defeating any
>execlp path manipulation. The load library path remains a
>vulnerability.
Okay, I might buy that argument in a server environment, where things get done
with full paths. On the other hand, if someone can fiddle the environment
of the server, I'd think they would be in a position to fiddle the configuration
of those full paths as well. Either the code which started the server can be
compromised, compromising it's environment as well as which server is running
and which config file it references, or it can't.
If you are worried about server security (a separate subject from the security
of the client-server transaction as noted earlier) then you secure the
server by not depending on anything which someone unauthorized can modify.
The only vulnerability you have from dynamic linking, that I know of, is that
the linker could be redirected to another library (the wrapper). The only
means I know of to do this are environment variables (set when the server was
started, and not modifyable during its operation unless someone implemented
some very bad opcodes in the server) or write access to the server binary (a
serious security breach).
A secure server started as a daemon at boot, or through inetd, should not be
able to have its environment compromised unless the system has been
substantially compromised as well (or someone makes a mistake in file access
permissions).
If you're worried about things exec'd by the server, then you use "execle"
instead of "execlp" (in a unix environment) to force the environment to be
what you want. That should remove any dependence on files in the servers "home
directory" which might be more readily compromised. I'd expect you would want
security handled in the server anyway, it's an obvious choke point.
I would agree that dynamic linking would be a potential weak point if the
person setting up the server were not careful about securing it, and hence
using dynamic linking could be said to increase the probability of a serious
problem arising from a misconfiguration. I don't see it as a weakness in
itself.
The only place I see dynamic linking being a problem is in the client scenario,
where a users home directory or active environment might be compromised by some
other program run by the user. In that scenario the users "path" could also be
compromised (my original argument) so I don't see dynamic linking adding to
the users vulnerability.
Do you see a different scenario that I missed?
Ken
-----
Ken Shores, Sr. Network Analyst The Charles Stark Draper Laboratory, Inc.
kss1376@pop.draper.com 555 Technology Square, Cambridge, MA 02139-3563
(617) 258-2529 Mail Stop 33